Codecov Report

Attention: Patch coverage is 22.80702% with 44 lines in your changes missing coverage. Please review.

Project coverage is 70.90%. Comparing base (e60990e) to head (87709c2).
Report is 5 commits behind head on unstable.

@@             Coverage Diff              @@
##           unstable    #1546      +/-   ##
============================================
+ Coverage     70.77%   70.90%   +0.13%     
============================================
  Files           120      120              
  Lines         65005    65108     +103     
============================================
+ Hits          46005    46165     +160     
+ Misses        19000    18943      -57     

Is there a concrete need for this, or are you just looking to make the API more usable by extending the use cases? We had discussed previously in Redis, and had decided to avoid having a large number of APIs, we would only support signed until someone indicated they clearly needed a 64 bit unsigned value. You can always restrict the value to be positive and cast it to unsigned (but just miss some of the high values).

Is there a concrete need for this, or are you just looking to make the API more usable by extending the use cases? We had discussed previously in Redis, and had decided to avoid having a large number of APIs, we would only support signed until someone indicated they clearly needed a 64 bit unsigned value. You can always restrict the value to be positive and cast it to unsigned (but just miss some of the high values).

Yes, we encountered some scenarios.

In some designs, uint64 is used as the ID, and the higher bits are used to store some information.
Logically, use creatULongLongConfig to manage configurations.

However, for the creatULongLongConfig method, it can only exceed ULLONG_MAX in the MEMORY_CONFIG configuration item. so, I think we need a configuration to support a larger range.